Retail businesses often use a point of sale (“POS”) system at checkout to automate customer transactions. These POS systems often include a POS application designed to process transactions, accept payments, perform complex tasks such as managing inventory or tracking customers, and so on. POS applications typically support a predefined number of payment formats, such as cash, credit cards, gift cards, and checks. For each payment format, the POS application has an associated set of workflows for processing payment transactions, such as tender transactions, split tender transactions, return transactions, void transactions, and so on. A workflow defines a set of steps, including some optional steps, for processing a payment transaction. For example, a workflow for processing a tender payment transaction involving a credit card may include steps such as swiping a credit card through a Magnetic. Stripe Reader (“MSR”), keying in a credit card number and expiration date, checking photo identification, checking a Card Verification Value (“CVV”), sending information to a financial services provider for authorization, printing a receipt, and verifying a customer's signature. For each payment format, a POS application may support a number of configured instances of the associated workflow. The POS application uses these configured workflow instances, or “payment methods,” to process payment transactions. For example, a MasterCard credit card payment method may include swiping a credit card, checking photo identification, sending information to a financial services provider for authorization, printing a receipt, and verifying a customer's signature. As another example, an American Express credit card payment method may include keying in credit card information, acquiring a CVV, sending information to a financial services provider for authorization, printing a receipt, and verifying a customer's signature. Additionally, a POS application may allow a user to configure a new payment method by selecting options associated with a payment format workflow. For example, a merchant may add a “telephone” credit card payment method that only requires keying in credit card information and obtaining a CVV.
FIGS. 1 and 2 are display pages illustrating user interface screens a typical POS application may use to allow a user to select and configure options for a payment format workflow. FIG. 1 shows display page 100, generated by the POS application, which includes a list of available payment formats 110. Upon selection of a payment format, the POS application may populate drop-down list 120 with the available payment methods associated with the selected payment format, in this example, a credit card payment format. After selecting a payment method, the user may click “configure” button 130. Alternatively, if the user wishes to configure a new instance of the payment format workflow, the user may click “new” button 140 after selecting a payment format. FIG. 2 shows display page 200, generated by the POS application, which includes the current selection of workflow options 220-225 associated with the payment method selected in FIG. 1. Had the user clicked “new” button 140 on display page 100, the POS application may display a page similar to display page 200 but with each of the workflow options unselected or selected according to default settings and without a payment method name. Display page 200 allows a user to adjust the workflow options associated with a payment method. When the user clicks “done” button 230, the POS application stores the currently selected workflow options so that the POS application can use the payment method to process payment transactions using the selected options.
FIGS. 3-5 are display pages illustrating user interface screens a typical POS application may use to process a tender payment transaction. FIG. 3 shows display page 300, generated by the POS application, which includes a list of available payment formats 301-303 and a text box 310 where a user can enter an amount for the payment transaction. Once the user has selected a payment format and an amount, the user may click “tender” button 320. In this example, the user has selected the credit card payment format. FIG. 4 shows display page 400, generated by the POS application, which includes a list of supported credit card payment methods 401-403. Once the user has selected a payment method, the user may click “tender” button 420. FIG. 5 shows display page 500, generated by the POS application, which includes instructions 501-504 for processing the payment transaction using the selected payment method. These instructions may include instructions common to all payment methods associated with the selected payment format. For example, a debit card workflow may always instruct a user (i.e., a cashier) to acquire a PIN for a tender payment transaction. Once the steps are completed, the user may click “done” button 510 to finalize the transaction.
POS applications may be preconfigured to support a predetermined number of payment formats and payment methods. Because POS applications from different providers support different payment options, a merchant may find it difficult to find a POS application that supports each of the payment options the merchant needs to support its customer base. For example, a merchant may have customers that pay with various credit cards, customers that pay with food stamps, and customers that pay with checks. If the merchant cannot find a POS application that supports all of these payment formats, the merchant may risk losing customers. Additionally, new payment formats and payment methods that a merchant would like to support may be developed or become more common. For example, a merchant may wish to support loyalty cards to reward loyal customers. As another example, a government may issue Electronic Benefit Transfer (“EBT”) payment cards to victims after a natural disaster. As another example, a new credit card may require biometric data to process a payment transaction. Merchants may also encounter different payment options as they expand into new markets where different payment options are more common.
Some POS applications provide limited support for customizing options for built-in payment formats and payment methods. For example, a POS application may allow a merchant to rename a payment method or select whether a signature is required during a payment transaction. However, merchants can only customize the payment options provided by the POS application provider and typically have no ability to incorporate additional payment formats or payment methods that are beyond the scope of the configurable options the POS application provides. Similarly, merchants cannot configure payment methods to use financial services providers that the POS application does not support. Some POS application providers may offer periodic updates to POS applications. For example, merchants may be able to download and install upgrades to the POS application from a website. Merchants, however, typically cannot extend POS applications to support additional workflows beyond configuring options for the predefined workflows. Thus, merchants using the POS application need to wait until the POS application provider chooses to incorporate new payment formats, payment methods, and financial services providers into the application.
Processing a payment transaction may require interaction with a financial services provider, such as Total System Service, Inc. (“TSYS”) or First Data Corporation (“FDC”). For example, a credit card tender payment transaction may include verifying credit card and account balance information with a financial services provider to authorize a transaction prior to completing the transaction. Different financial services providers offer different services and at different rates. A merchant may find it beneficial to establish relationships with different financial services providers and use the services of each when most appropriate. POS applications provide support for a predefined number of financial services providers. In the same way that POS applications limit the payment formats and payment methods that a merchant can support, POS applications limit the merchant's ability to use the services of different financial services providers. Additionally, a POS application can only support payment transactions supported by the financial services providers available to a POS application. If, for some reason, a financial services provider were to become unavailable, a POS application may no longer be able to process certain payment transactions.